﻿<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
    <title>Simplest possible thing</title>
    <link href="Content/Site.css" rel="stylesheet" />
    <link href="Content/fontawesome/font-awesome.css" rel="stylesheet" />
    <link rel="stylesheet" href="http://twitter.github.com/bootstrap/assets/css/bootstrap.css">
</head>
    <body>
       <header>
    <div class="content-wrapper">
        <div class="float-left">
            <p class="site-title">
                <a href="">Simplest Possible Thingie</a></p>
        </div>
    </div>
</header>
<div id="body">
    <section class="featured">
        <div class="content-wrapper">
            <hgroup class="title">
                <h1>Welcome to CQRS + REST!</h1>
                <h2>While in CQRS commands and queries live in disparate systems, they will be represented as a unified resource at the API Layer.</h2>
            </hgroup>
            <p>
                This prototype exposes Greg Young's <a href="https://github.com/gregoryyoung/m-r">m-r</a> sample
                - which has been the de-facto CRQS+ES (ES = Event Sourcing) sample in the community - through a
                RESTful interface.
            </p>
            <p>
                This prototype exemplifies:
                <ul>
                    <li>Forming the API's Public Domain abstracing Server/BoundedCountext's internal domain. 
                        Public domain is composed of DTOs and separate commands.
                    </li>
                    <li>
                        Service has been exposed as resources. Resource accept GET, POST, 
                        DELETE and PUT requests - currently OPTIONS is not implemented. 
                        <ul>
                            <li><pre>GET /api/InventoryItem</pre>  [gets all items]</span></li>
                            <li><pre>GET /api/InventoryItem/{id}</pre> [gets detail of a single item]</li>
                            <li><pre>POST /api/InventoryItem</pre> [creates an item]</li>
                            <li><pre>POST /api/InventoryItem/{id}</pre>* [checks in stock items to the inventory]</li>
                            <li><pre>POST /api/InventoryItem/{id}</pre>* [removes stock items from the inventory]</li>
                            <li><pre>PUT /api/InventoryItem/{id}</pre> [renames an item]</li>
                            <li><pre>DELETE /api/InventoryItem/{id}</pre> [de-activates an item]</li>
                        </ul>
                    </li>
                    <li>
                        Operations marked with the * above require passing the command type as described
                        by the <a href="http://byterot.blogspot.co.uk/2012/12/5-levels-of-media-type-rest-csds.html">5 levels of media type.</a> 
                        This helps to avoid RPC-style URLs where a verb is defined on the top of
                        a resource: so instead of <pre>/api/InventoryItem/{id}/AddToStock</pre>, we send a request with 
                        media type <pre>application/json;domain-model=CheckInItemsToInventoryCommand</pre>. This also
                        moves away from the common misconception that HTTP Verbs must be mapped to CRUD.
                    </li>
                    <li>
                        Exposing ES concurrency through HTTP's ETag and If-Match and If-None-Match 
                        conditional PUT and GET requests. 
                    </li>
                    <li>
                        Enabling caching on the top of single resources and returning 304 for resources that
                        are not modified. Also returning 412 (PreconditionFailed) on unsuccessful If-Match
                        conditional PUT calls.
                    </li>
                    <li>
                        As per <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.11">RFC 2616</a>, ETag has been opacified so that the client cannot guess the values -
                        this would have been possible if we had exposed version numbers directly. 
                    </li>
                    <li>
                        Other HTTP-level semantics such as status codes, populating <pre>Location</pre> header
                        after POST, etc.
                    </li>
                </ul>
            </p>
        </div>
    </section>
        <script src="Scripts/angular.js"></script>
        <script src="Scripts/inventory-item.js"></script>

    <section class="content-wrapper main-content clear-fix">
        <div ng-app="cqrsSample">
             <div ng-view></div>
        </div>

    </section>
</div>
    </body>
</html>
